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(54) Method and apparatus for enhancing the portability of an object oriented Interface among 
multiple platforms 



(57) The present invention is directed to providing 
an ability to re-host, or port, an object oriented graphical 
user interface Inrplementation from a native window- 
based platform, or environment, to another window- 
based platform, or environment. Exemplary embodi- 
ments abstract any notifications (e.g., events, state 
changes or "interests") which occur in the native envi- 
ronment as behavioral specifications. These behavioral 
specifications, (i.e., traits or protocols) can be used as 
part of a conformance negotiation to determine, during 
the execution lifetime of the graphical user interface, 
whether a particular client side object will conform with 
the behavioral specifications which have been 
abstracted from server side events associated with a 
different object. Where the conformance negotiation 
proves successful, abstract notifications can flow 
between particular instances of objects to model the 
state of the system, rather than using native implemen- 
tations of events. During the execution lifetime, other 
objects can dynamically establish relationships with 
object classes containing abstracted notifications for the 
purpose of receiving the abstracted notifications. 
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Description 

BACKGROUND OF THE INVENTION 
5 Reld of the Invention 

The present invention relates generally to network-based graphical user interfaces. More particularly, the present 
invention relates to systems and methods for enhancing the portability and maintainability of an object oriented inter- 
face among multiple platforn^ such that the interface can. for example, be used with a client/server environment that 
10 integrates any of a variety of different hardware and/or software platforms. 

State of the Art 

Known graphical user interfaces provide application developers with an application program interface (API) that 

75 includes a collection of objects, such as scroll bars, push buttons, text entry fields and so forth. An object oriented 
graphical user interface (QUI) typically includes a hierarcNcal collection of these objects in a "toolkit". 

The behavior of a graphical user interface within a system Is defined by interactions between the objects in the cli- 
ent of a client/server environment and the window-based system server. A paradigm used to represent defined interac- 
tions between the objects is often referred to as a "model-view-controlier" {UNO) paradigm of object interaction. The 

20 model-view-controller paradigm fomnally defines the manner by which changes in state occur within at least part of the 
system (e.g., a timer of the system), and how those changes are to be communicated to, or ref lected in, other parts of 
the system that have established an interest in observing such state changes (such as a displayed clock). The controller 
can be considered a set of rules which define how state changes implemented in response to a model will affect a view. 
Using the model-view-controller paradigm, the toolkit can be considered a hierarchical collection of models, views and 

25 controllers that implement the graphical user interfaca 

Rgure 1 A illustrates an abstract representation of interaction among a model 1 02, a view 1 04 and a controller 1 06. 
wherein the model can be considered stored data, and the controller can be considered the rules by which the model 
and the view interact Arrows 108 in Rgure 1 A depict the most general model-view-controller paradigm wherein state 
changes can flow in both directions. 

30 Referring to Rgure 1 B those skilled in the art will appreciate that the distinctions between the model, the view and 
the controller often overlap in implementation even though the model, the view and the controller are conceptually dis- 
tinct For example, a scroll bar object 1 12 of an object oriented graphical user interface can represent both a controller 
as well as a view. The scroll bar of Rgure 1 B is a view when, for example, it graphically represents the percentage of a 
text file 1 14 which has been, or is being, displayed in a text view 1 16 O.e.. anywhere from zero percent to 100 percent). 

35 The scroll bar responds to a series of control events generated by a mouse to display the current location of the scroll 
bar on a monitor. As referenced herein, an "event" represents information of a state change which is particular to imple- 
mentation on one window-based platform and generic in concept across window-based platforms between which port- 
ability is desired. 

In this example, the scroll bar 112 can also be a controller which is used to initiate, or control, the updating of a dis- 
40 play of text from the text file 1 14 in response to movements of the mouse. That is, by "clicking" on the scroll bar and 
moving its image 1 12 vertically, the scroll bar serves as a controller which generates a stream of notifications that are 
sent to and used by the view 1 1 5 to continuously redraw the scroll bar as It is moved up and down the display, thereby 
changing the presentation of the scroll bar, and thus the contents of file 1 1 4 which are displayed. In the Rgure 1 B exam- 
ple, the model (I.e., the text file 1 14) defines how user activation of the mouse will affect a displayed view of the scroll 
45 bar and thus the text file. 

In a typical window-based system, such as the UNIX based X-Window System™ from the Massachusetts Institute 
of Technology, state changes within the system are communicated to graphical user interface clients via "events", in a 
manner similar to that described above with respect to the model-view-controller paradigm. When a window-based sys- 
tem is associated with an object oriented graphical user interface toolkit, the toolkit maps state changes in the window- 
so based system, reported via window system events, onto an object oriented model-view-controller. The window-based 
system event results in a method invocation on an object of the graphical user interface to notify it of the stale change. 

The definition of the relationships between models, views, and controllers is established by implementation-specific 
definitions of object "classes". Although the relationships between particular instances of models, views and controllers 
can be dynamically specified during the lifetime of an application, these relationships are not alterable at the time of 
55 execution o1 a client-side application except through assignment between instancy of particular implementation^^^^ the 
models and views. This is the case, for example, where object oriented systems are implemented in programming lan- 
guages such as C + 

Because the interactions between objects are defined by a model-view-controller developed as a platform specific 
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implementation for use with a specific window-based environment, the toolkit cannot be readily ported from one win- 
dow-based platform to another. That is, an "event" found in a native window-based platform for which a toolkit was 
implemented can differ significantly in implementation from another window-based platfonm to which the toolkit is to be 
ported. Further, native implementations are amply not designed with portability to other environments as a goal, such 

5 that platform dependencies are not typically localized or abstracted within the native platform. An "event" defined for 
one platform Is usually differ^rt in implementation with reject to other platforms in tenns of the information which is 
provided (i.e., different semantics), as well as the format with which any such infomnation is provided (i.e.. different syn- 
tax). The amount of computer code which must be revised to use a toolkit defined for one window-based platform with 
another window-based platform is therefore excessive and Impractical. As such, significant problems exist in porting an 

70 object oriented graphical user interface from a native window-based platfomn to another window-based platform (e.g., 
such as porting from the NeXTSTEP environment of NeXT Computer Company onto another wiralow-based platform 
such as the X-Window System™). 

Accordingly, It would be desirable to develop a method by which platform dependencies can be .localized and 
abstracted for use with an object oriented graphical user interface, wherein object interactions are defined with respect 

75 to an abstract model-view-controller For example, it would be desirable to abstract the events received from a window- 
basej system so that the prinrtary portions of code used to represent a toolkit of an object oriented graphical user inter- 
face can remain unchanged, and therefore be easily ported to any of a variety of window-based platforms. 

SUMMARY OF THE INVENTION 

20 _ , 

The present invention is directed to providing an ability to re-host, or port an object oriented graphical user inter- 
face implementation from a native window-based platform, or environment, to another window-based platform, or envi- 
ronment. In accordance with exemplary embodiments, any notifications (e.g,. events, state changes or "interests") 
which occur in the native environment are abstracted as behavioral specifications. These behavioral specifications. 

25 (i.e., traits or protocols) can be used as part of a conformance negotiation to determine, during the execution lifetime of 
the graphical user interface, whether a particular client side object will confonm with the behavioral specifications which 
have been abstracted from server side events associated with a different object. Where the conformance negotiation 
proves successful, abstracted notifications can flow between particular instances of objects to model the state of the 
system, rather than using native implementations of events. During the execution lifetime, other objects can dynamically 

30 establish relationships witii object classes containing abstracted notifications for the purpose of receiving the 
abstracted notifications. 

Exemplary embodiments of tiie present invention tiiereby create an abstraction layer within tiie native implementa- 
tion that separates and localizes platfomi implementation dependendes throughout tiie toolkit of tfie object oriented 
graphical user interface. Exemplary embodiments significantiy extend ttie client side model-view-controller paradigm 

35 and its application within user interlaces to reduce the magnitude of the porting task, and to accommodate porting of 
an interface among different window-based platforms. 

Generally speaking, exemplary embodiments of the present invention are directed to a metiiod and apparatus for 
.porting a toolkit of a graphical user interface to a window-based platform, comprising tiie steps of: receiving a native 
notification of a state change from a window-based platform; and representing said native notification as an abstracted 

40 notification during execution of tiie graphical user interface.: said abstracted notification constituting a behavioral spec- 
ification of the native notification which is independent of inpiementations specific to said window-based platform. In 
accordance with tiie present invention, arbitrary implementations of models, views and controllers arbitrarily conform to 
abstracted notifications. Absti-acted notifications which have been defined in the object oriented graphical user interface 
toolkit can be implemented using a programming language of tiie graphical user interface. Thus, a toolkit established 

45 as part of a graphical user interface can be quicWy and cost-effectively ported across any of a variety of window-based 
systems. 

BRIEF DESCRIPTION OF THE DRAWINGS 

so The foregoing and otiier features of the present invention will become apparent to tiiose skilled in tine art upon read- 
ing the following description of preferred ent)odiments of tiie invention in conjunction witii tiie accompanying drawings, 
wherein: 

Figure 1 A shows an abstract representation of a model-view-confrolier paradigm; 
55 Rgure 1 B is an exemplary application of the abstract representation shown in Rgure 1 A; 

Figure 2 illustrates an exemplary flowchart for porting a user interface from a first window-based platfonri to a sec- 
ond window-based platform in accordance wttii an exemplary embodiment of the present invention; 
Figure 3 illustrates an exemplary system configured in accordance with tiie present invention for porting a client- 
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side interface from a first window-based platform to a second window-based platfonn; 
Rgure 4 is a grapliic illustration of aspects of the invention; and 

Rgure 5 illustrates a graphical depiction of an ability of a system configured in accordance with the present inven- 
tion to dynamically establish relationships between arbitrary instances of objects confonning to a given behavioral 
5 specification with other objects conforming to the same behavioral specification. 

DETAILED DESCRIPTION OF THE PREFERRED EWIBODIMEMTS 

Figure 2 illustrates an exemplary flowchart 200 for porting a toolkit of a graphical user interface to a window-based 

ID platform (e.g.. from a first window-based platform to a second window-based platform). A first phase of the Figure 2 
flowchart constitutes a definition phase wherein the toolkit is defined using abstracted notifications of a window-based 
platform. A second phase of the Figure 2 flowchart constitutes an execution phase, during which notifications from any 
window-based system are represented as gbstract notifications used to establish Interaction between the window- 
based system and the graphical user interface toolkit. 

15 The start block 202 and steps 204 and 206, constitute the d^in'rtion phase, while the remaining steps constitute the 
execution phase. In step 204 of the Figure 2 flowchart one or more native notifications (\.b„ events, state changes or 
"interests") implemented with respect to a first window-based platform (i.e., the native platform) are translated into, 
abstracted notifications for use in defining the graphical user interface. As a result, each object of the graphical user 
interface toolkit can be registered with an abstracted notification received from any of plural window-based platforms. 

20 As those skilled in the art will appreciate, a notification can correspond to an event such as a key stroke, activation 
of a push button, an iconified window, and so forth. The events received from the host window-based platform to indi- 
cate state changes are, in accordance with exemplary embodiments, encapsulated into abstract notifications repre- 
sented as functional signatures of object interface definitions. The functional signature used to represent an abstract 
notification constitutes a behavioral specification (6.g.. forma! trait or protocol) to which model, view and controller 

25 object implementations can be made to conform. 

The model-vlew-controller paradigm is further extended to support multiple views expressing the same interest on 
a single model or controller, and to support single views that can express interests on multiple models or controllers. 
That is. multiple objects of tiie graphical user interface can be registered with an abstract notification received from any 
of multiple window-based platforms. 

30 In step 206 of the definition phase, tine notifications are implemented (e.g., expressed formally in an implementation 
language of the graphical user interface) as a behavioral specification using arbitrary object implementations. That is, 
an abstracted notification is implemented in at least one object class of tiie graphical user interface via tiie behavioral 
specification. However, tiie abstracted notification can be passed between objects of arbitrary implementation wfthin tiie 
object oriented graphical user interface toolkit 

35 Due to tiie implementation of the abstracted notifications as behavioral specifications supported by the implemen- 
tation language, arbitrary instances of objects conforming to the behavioral specifications can dynamically establish 
ari5itrary relationships with otiier objects confonning to the same behavioral specifications over tiie execution lifetime of 
the graphical user interface, thereby creating a highly portable system. More particularly, tiie encapsulation of events 
into functional signatures is exploited to implement an object conformance verification. By encapsulating events of tiie 

40 native window-based system as functional signatures which are intended to correspond to interface definitions of one 
or more objects, conformance of any given object witii an event received from any window-based system can be verified 
during the execution lifetime of the graphical user interface In which the object is deployed. 

Following tiie definition phase, an execution phase can be initiated wherein tiie graphical user interface toolkit inters 
acts with any window-based system (i.e., tiie native platform used to implement the toolkit or any otiier window-based 

45 platform). This is represented by step 208, wherein a relationship between the at least one object with other objects can 
be dynamically established using conformance verification during runtime of an appiication. 

Conformance among objects is established by verifying conformance of each object with the abstracted notification 
using dynamic (i.e.. runtime) binding mechanisms, such as tiiose exhibited by such programming languages as objec- 
tive C. These dynamic binding mechanisms are used to formally define the notifications in tiie implementation language 

so of the native window-based platform. As such, arbitrary implementations of models, views and controllers which con- 
fomi with an arbitrary notification are provided. In accordance with tiie present invention, conformance verification is 
established using a runtime negotiation with an arbitrary object. 

Once relationships have been established between objects, the objects can freely send and receive notifications as 
represented by step 210. As tiiose skilled in the art will appreciate, tiie runtime negotiation can be performed witii 

55 respect to any number of arbitrary objects, to thereby establish and destroy dynamic polymorphic relationships during 
the execution lifetime of the object oriented graphical user interface, as represented by steps 212 and 214. 

Thus, in accordance with exemplary embodiments, tiie model-view-controller paradigm of tiie graphical user inter- 
face is extended into an "interest" model, wherein views can express different interests in multiple models and control- 



4 



EP0822 484A2 



lers. The foregoing steps can be repeated via the loops associated with steps 21 2 and 21 4 for any number of ongoing 
notifications, until the execution life of the graphical user interface is connpleted in "Ercl" step 216. 

in accordance with exemplary emfc»odiments. an object oriented graphical user interface is easily and dynamically 
ported to any of a variety of window-based systems. That is, a graphical user interface toolkit can be dynamically ported 

5 from a native environment for which it was originally implemented (e.g., Microsoft™ Windows) to any other target win- 
dow-based platform (e.g., the X window System™), without encountering the traditional difficulties associated with 
rehosting a toolkit from one piatfonm to another. 

In accordance with exemplary embodiments, abstractions are used to remove system dependencies upon concep- 
tual and implementation features of the native platfprm that have no direct counterpart in the target platform. The coun- 

10 terpart implementation features significantly undermined a traditional rehosting of a graphical user interface, since the 
features in question were fundamental to tiie graphical user Interface system and were widespread in their deployment 
within the original implementation. Thus, the amount of effort typically required to initially port tine inrplemeritation code, 
and to maintain it, was quite costly. However, in accordance with exemplary embodiments of the present invention, sig- 
nificant differences between a native platform and a target platform are handled using abstracted behavioral spedfica- 

15 tions to, for exanrple, notify a client-side of window-based system state changes which affect the client-side. 

Figure 3 illustrates an exemplary system for inrplementing the flowchart of Rgure 2. The exemplary Rgure 3 sys- 
tem 300 includes a server side 302, a client-side 304 and peripheral inputs 306 to tiie server side, such as a keyboard 
and/or mouse input. Notifications are passed from tiie window-based platform of tiie server side to tiie graphical user 
interface on the client side via an interprocess communication connection 308. In the Figure 3 system, window-based 

20 platform events, such as a keyboard actuation, actuation of an iconified window, or a mouse movement are repre- 
sented (e.g.. ti-anstated) by the client side toolkit as abstract notifications. 

As described with respect to Figure 2, events of a window-based system are not merely passed to an object of the 
graphical user interface as was the case with traditional systems. Rather, each object of the. graphical user interface 
must inHialiy register an interest during a runtime negotiation with abstractions (i.e., behavioral pacifications) of one'or 

25 more notifications that can be received from' a window-based system. In the Figure 3 example, an event dispatch object 
of tiie graphical user interface is used to map abstracted notifications from tiie window-based platform to one or more 
arbitrary objects of tiie graphical interface tiiat have registered an interest in a particular notification during a runtime 
negotiation. 

In operation, when the event dispatch object receives a concrete event from the window-based platform of tiie 
30 server-side, it maps this event into an abstract notification, and passes tiie abstract notification onto one or more objects 
of the graphical user interface. As a result, any objects which initially registered tiiemselves as having an interest in the 
notification will receive tiie notification. Thus, tiie event dispatch object constitutes a mechanism for passing the notifi- 
cations to client-side objects. 

As tiiose skilled in tiie art will appreciate, tiie functionality described above can be implemented on any computer 
35 readable medium. For example, such a medium can be resident in the graphical user interface 304 of Figure 3, or can 
be resident in a computer readable.medium tiiat can be used in conjunction witii tiie graphical user interface 304. In tiiis 
latter case, a computer programmed product 310 can be encoded witii a computer program for porting a toolkit of a 
graphical user interface to a window-based platform. The computer programmed product can, for example, include a 
computer readable storage medium 312 for storing data, such as the atjstractions of the notifications from tiie native 
40 window-based platform and/or. a table for mapping events from tiie target window-based platform to the various 
abstracted notifications. 

The computer programmed product 310 can further include a computer code mechanism embedded in the com- 
puter readable storage medium for causing the conputer readable storage medium to execute tiie conrputer code. For 
example, the computer code mechanism can include a first computer code device 312 configured for receiving a native 

45 notification of a state change from a window-based platform, and a second computer code device 314, coupled to tiie 
first computer code device, for representing the native notification as an abstracted notification during execution of the 
graphical user interface. As described previously, tiie native notification can be mapped to one or more abstracted noti- 
fications. The abstracted notifications, in accordance with exennplary embodiments, constitute a behavioral specifica- 
tion of the native notification which is independent of implementations specific to both tiie native and the target window- 

50 based platforms. 

In the exemplary Figure 3 embodiment, the computer code mechanism can include any number of computer code 
devices. For example, a tiiird computer code device 318 can be included for verifying conformance of at least one object 
in the graphical user interface toolkit with the behavioral specification constituted by tiie abstracted notification. 

The foregoing features will be further illustrated witii respect to the following example. Assume that a user activates 
55 a key on the keyboard of the peripheral input 306. This action results in the sending of a keypress event from tiie win- 
dow-based platform to tiie graphical user interface on tiie client-side. The keypress event includes two significant 
aspects: (1) the semantics of ttie event; and (2) the format, or syntax, of the event. The keypress event is transferred to 
the client side via the interprocess communication connection 308. 
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As the keypress event is received by the object oriented graphical user interface of the client-side, the event dis- 
patch object looks at the information and determines vi^here it should be forwarded. The event dispatch object then for- 
wards the information accordingly. For exanple, where the keypress con-esponded to a depressing of the letter "A" key 
in combination with the "shift" key (i.e., to signify an upper case "A"), the event dispatch object will, upon receipt of the 
keypress event information, pass information representing an "A" to a te)Ct field which then implements the diwing of 
an "A" on a display. That is, the event information is r^resented as an abstract notification which can be directed to 
objects that have registered an interest In the abstract notification via a runtime negotiation. 

In accordance with exemplary embodiments of the present invention, the toolkit has been implemented with 
respect to notrficalions of events which have been abstracted to represent only behavioral specifications of the events 
which will necessarily exist in any vinndow-based implementation (i.e.. a functional signature). For exanple, the seman- 
tics and syntax which would have typically been encapsulated in an event, and thereby restricted portability of the event 
to an object oriented interface implemented for a different window-based platforrri, are eliminated. Rather, the event is 
abstracted such that it Is Independent of Implementations specific to any parUculaf window-based system (i.e.. It is no 
longer specific to the native platform for which it was originally Intended). Only Infonnation of the notification which is 
common to: (1) the native window-based platform; and (2) a target window-based platfonn to which the toolkit has been 
ported Is used to recognize and correlate the event with an ol^ect on the client-side. In the foregoing example, common 
infonnation extracted from the event may merely result in denoting which letter was depressed {i.e., "a") as the behav- 
ioral specification for mapping the notification to an object on the client-side. 

To illustrate the abstracting of an event, a simplified example will be provided with respect to the encoding of everits 
associated with a button (e.g., keypress events). The code fragments set forth in the example express constructs readily 
familiar to those skilled in the art. The example demonstrates the abstracting of two different concrete window system 
events into a single "abstract" representation, and the expressing of that representation as a formal protocol between 
event sources and sinks. The example highlights the practical application of the invention in localizing platform depend- 
encies, resulting in the majority of the graphical user interface framework becorning platform independent and creating 
a formal protocol between event sources and sinks that results in a robust dynamic event model where relationships 
between sources and sinks can be modified during the lifetime of an application. 

For this example, consider the X Window System™ and the NeXTSTEP™ Window system wherein there exists a 
concrete window system event notification of a mouse, or pointer button press event In both systems, this event notifi- 
cation is delivered from the window system server to a client application that has been selected for receiving such noti- 
fications from the system, via platform dependent application program Interfaces and interprocess communications 
mechanisms. However each system has semanticaiiy different concrete representations for such notifications, both in 
terms of their syntax and semantics. For example, in the X Window System the event is described by the following C 
type definition and constants (for details, see "The X Window System", by Scheifler & Gettys, Digital Press, 1992 ISBN 
1-55558-088-2): 



typedef struct { 
int type; 
unsigned long serial; 
Bool send_event; 
Display* display; 
Window window; 



// 



// 



// 



// 



// 



serial number of last request processed 
synthetically generated 
window server client reference 
the window the event is delivered to 



- - ButtonPress 



Window 



root; 



// 



root window of screen 
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Window subwindow; // the window in which the event 

occurred 

Time time; // server timestamp 

int X, // pixel based, origin top left 

int x_root, // screen relative coords 

y_root; 

unsigned int state; // state of keybd modifiers 

unsigned int button; // which button is pressed? 
Bool same_5creen; 
} XButtonEvent; 

typedef XButtonEvent XButtonPressedEvent; 
typedef XButtonEvent XButtonReleasedEvent; 
/♦ constant for "type" field above */ 
#define ButtonPress 4 
/* constants for "state" field above */ 
#define ShiftMask (1<<0) 
#define LockMask (1<<1) 
#define ControlMask (1< < 2) 

#define Modi Mask (1<<3) 
#define Mod2Mask (1< < 4) 

#define Mod3Mask (1< < 5) 

#define Mod4Mask (1< <6) 

#define ModSMask (1< < 7) 

/♦ constants for "button" field above V 
#define Button 1 1 
#define Button2 2 
#define Button3 3 
#define Button4 4 
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#define Buttons 5 

In the NeXTSTEP Window System the Button event is defined as follows (for details, see "NeXTSTEP General Ref- 
erence (volume 2)" by NeXT Computer Inc, Addison Wesley. 1992 ISBN 0-201-62221-1): 

/* EventData type: defines the data field of an event V 
typedef union { 

strua { /* For mouse events */ 

short reserved; 

short eventNum; /* unique identifier for this 

button */ 

int click; /* click state of this event */ 

unsigned char pressure; /* pressure value: 

0-none, 

255 -full*/ 

char reserved!; 
short reserved2; 
} mouse; 

/* other event type data deleted for clarity */ 
} NXEventData; 
/* The event record! */ 
typedef struct { 
float x; 
float y; 
} NXPoint; 

typedef struct _NXEvent { 

int type; /* An event type from 

above */ 

NXPoint location; /* Base coordinates in 

window, from lower-left */ 
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long time; /* vertical intervals since 

launch */ 

int flags; /* key state flags V 

unsigned int window; /* window number of 

assigned window */ 
NXEventData data; /* type-dependent data */ 
DPSContext ctxt; /* context the event came 

from */ 



} NXEvent, ♦NXEventPtr; 
/* constants for "type" field above */ • 
#define NX_LMOUSEDOWN 1 /* left mouse-down 

event */ 

#define NX_LMOUSEUP 2 /* left mouse-up 

event */ 

#define NX^RMOUSEDOWN 3 /* right mouse^lown 

event */ 

#define NX_RMOUSEUP 4 /* right mouse-up 

event */ 

#define NX^MOUSEMOVED 5 mouse-moved 

event */ 

#define NX__LMOUSEDRAGGED 6 /* left mouse-dragged 

event */ 

#define NX_RMOUSEDRAGGED 7 /* right 

mouse-dragged event */ 
#define NX_MOUSEDOWN NX_LMOUSEDOWN 

/* Synonym */ 

#define NX^MOUSEUP NXJMOUSEUP 

/* Synonym 
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#define NX_MOUSEDRAGCED NX_LMOUSEDRAGGED 

/* Synonym */ 
/* constants for "flags" field above */ 
#define NX_ALPHASH1RMASK 

(1 < < 16) /* if alpha 

lock is on */ 
#define NXJHIFTMASK (1<<17) /* if shift key 

is down */ 
#define NX_CONTROLMASK (1<<18) /* if control 

key is down */ 
#define NX_ALTERNATEMASK (1 < < 19) /* if alt key is 

down */ 
#define NX_COM^MNDMASK (1 < < 20) /* if command 

key is down */ 
#define NX_NUMERICPADMA5K (1 < < 21) /* if key on 

numeric pad */ 
#define NX_HELPMASK (1 < < 22) /* if help key 

is down */ 

/* Device-dependent bits */ 

#define NX_NEXTCTRLKEYMASK (1 < < 0) /* control key 

*/ 

#define NX_NEXTLSHIFTKEYMASK 

(!<<!) /* left side 
shift key */ 

#define NX_NEXTIISHIFTKEYMASK 

(1 < < 2) /* right side 
shift key */ 

#define NX NEXTLCMDKEYMASK 
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(1 < < 3) /* left side 
command key */ 

5 

#define NX_NEXTRCMDKEYMASK 

(1 < < '4) /* right side 
command key */ 

#define NX^NEXTLALTKEYMASK (1 < < 5) /* left side alt 

key */ 

#define NX_NEXTRALTKEYMA5K (1 < < 6) /* right side 

alt key */ 

#define NX JTYLUSPROXIMITYMASK 

(1 < < 7) /* if stylus is 
in proximity 
* (for tablets) */ 

25 

#define NX_NONCOALSESCEDMASK 

(1 < < 8) /* event was 
generated with event 
coalescing disabled */ 



35 

It is apparent from the definitions above tliat the two Implementations differ significantly in both their concrete syn- 
tax and semantics. Thus, these definitions cannot be used in their native form to create an implementation of a graph- 
ical user interface toolkit that is portable between both platforms without comprehensive conditional compilation 
directives to create parallel implementations for each target window system. However, in accordance with exemplary 
40 embodiments of the present invention, a common definition for a button press event can be abstracted that will be port- 
able across both window systems, making the vast majority of the code implementing the toolkit platform Independent, 
through the localization of the platform dependent code into a single, or relatively few components of the toolkit. 

Given the concrete window system event notifications defined above, a first step of an implementation according to 
the exemplary embodiments is to define a common abstraction of the concrete events. This example wilt use the Objec- 
ts tive-C programming language since this is the implementation language used in programming systems such as NeXT- 
STEP and OpenStep (for the X Window System). An abstract event is used to define the event type, its source, and 
other fundamental information common to all event abstractions: 



so 



55 
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©interface AbstractEvent : Object 
{ 



enum { 



} 



AEButtonPress, 
AEButtonRelease, 
AEMouseMoved, 
II ... 

eventType; 



SystemEventDispatcher eventDispatcher; // object 

that maps and dispatches 
events from the platform 
window system. // 
eventSerial; // serial number 
eventTimestamp; // system 
timestamp 



unsigned int 
unsigned long 



} 

II ... 

@end 



Next, the concept of an event associated with a "window" is introduced; that is, a concept common to both target 
platforms: 



©interface AbstractWindowEvent : AbstractEvent 



{ 

unsigned int eventWindow; // id of window event 

occurred on 

} 

// ... 
@end 

Finally, a particular abstraction is defined for a button press event, containing information relevant to both target 
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platforms, but with a synthesized syntax and semantics distinct from those found in the concrete events: 

typedef enum { 

AKbdEShiftModifier - (1 < 0), 
AKbdECtrlModifier - (1 < 1), 

// ... 

} AKbdEventModifiers; 

©interface AbstractButtonPressEvent : AbstractWindowEvent 
{ 

float eventX; 
float eventY; 
20 enum { 

ABPELeftButton, 
ABPEMiddleButton, 
2^ ABPERightButton 

} eventButton; 

AKbdEventModifiers eventKbdModifiers; 



75 



30 



35 



SO 



55 



} 

//... 

@end 



A hierarchy of abstract window system event objects, recognizable to those skilled in the art, has thus been defined 
40 as containing a synthesis of the information found in the concrete event systems of the X Window. System and the 
NeXTSTEP Window System for mouse button press events. Next, an interface to an object hierarchy is defined that 
allows an arbitrary object (the observer or sink) to express an interest In observing notifications from another object (the 
observee or source) via a particular protocol or interface specification: 

<s @i nterface Object{ I nterestP rotoco I Registrar i on) 

- (Bool) addObserver: (Object *) observer 

forProtocol: (Protocol*) interestProtocol; 

- (Bool) removeObserver: (Object *) observer 
forProtocol: (Protocol*) interestProtocol; 

@end 



A set of protocols is then defined based upon the abstract event definitions. These protocols describe the formal 
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interface between arbitrary objects that may emit and receive notifications of clianges in state of the system as repre- 
sented by ttie abstract event descriptions detailed above. 

©protocol AbstractEventObserverProtocol 

- (void) gotEvent: (AbstractEvent*) theEvent 

fronnSource: (Object *) theEvenlSource; 

@end 

©protocol AbstractWindowEventObserverProtocol 

- (void) gotWindowEvent: (AbstractWindowEvent*) 
theWindowEvent 

fromSource: (Object *) theEventSource; 

©end 

©protocol AbstractButtonPressEventObserverProtocol 

. (void) gotButtonPressEvent: (AbstractButtonPressEvent*) 
theWindov^Event 

fromSource: (Objea *) 

theEventSource; 

©end 

Having defined these abstract protocols, a "ButtonContror object that wishes to receive these notifications can be 
defined: 
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©interface ButtonControl : Control 
<AbstractButtonPres5EventObserverProtocol, 
AbstractWindowEventObserverProtocol, 

//... 
> 

II... 

. (ButtonControl) newButtonControl; 

- (void) dealloc; 

. (void) gotBunonPressEvent: (AbstractButtonPressEvent*) 
theWindowEvent 

fromSource: (Object *) 
theEventSource; 

- (void) gotWindowEvent: (AbstractWindowEvent*) 

theWindowEvent 

fromSource: (Object *) 

theEventSource; 

//... 
@end 

Relevant parts of the implementation are then provided: 

©implementation ButtonControl 
- (ButtonControl) newButtonControl 

{ 

This method creates a new instance of a ButtonControl. As a side effect, the ButtonControl registers itself with the 
toolkit's "eventOispatcher" object to receive notifications of Button Press events. 

self - [super init]; 

Now, this object is registered with the window system event dispatcher in order to receive the protocol notifications. 
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[[SystemEventDispatcher eventDispatcher] 
addObserver: self 
forProtocol: 

©protocoKAbstractButtonPressEventObserverProtocol) 
return (ButtonControl*)self; 

}' 

- (void) dealloc 

{ 

This msthod is called to free instances of the ButtonControL As a side effect, the ButlonControl removes 
the eventDispatcher object: 

[[SystemEventDispatcher eventDispatcher] 
removeObserver: self 
forProtocol: 

©protocoKAbstractButtonPressEventbbserverProtocol) 
1; 

[super dealloc]; 

} 

- (void) gotSuttonPressEvent: (AbstractButtonPressEvent*) 
theWindowEvent 
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fromSource: (Objea* ) 
theEventSource 

{ 

// this method get invoked when a Button Press occurs 

on this 

// Control ... 

// .... do ButtonControl activation processing here ... 

} 

@end 

Having defined tiie graphical user interface toolkit objects in terms of these abstract protocols, the "SystemEvent- 
Dispatcher" class is implemented. For the present example, this is the only class in the event subsystem of the graphical 
user interface toolkit that includes window system dependent code: 

©interface SystemEventDispatcher : Object 
+ (SystemEventDispatcher) eventDispatcher; 

- (void) run; 

- (Bool) addObserver: (Object *) observer 
forProtocol: (Protocol*) interestProtocol; 

- (Bool) removeObserver: (Object *) observer 
orProtocol: (Protocol*) interestProtocol; 

- (void) dispatchAbstractEvent: (AbstradEvent*) absev; 
©end 

A class private interface to the SystemEventDispatcher is defined that encapsulates all of the platform dependent 
code: 

©interface SystemEventDispatcher(PlalfornnDependentStufO 
©private 

#ifdef XWindows 
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- (XEvent) _nextXEvent; // fetches next XEvent from X 

Window server 

- (void) _mapXEvent: (XEvent* ) xEvent 
OntoAbstractEvent: (AbstractEvent **) returnEvent; 
// ... 

#endif 

#ifdef NeXTSTEP 

- (NXEvent) ^nextNXEvent; // fetches next NXEvent from 

NeXTSTEP DPS 

- (void) _mapNXEvent: (NXEvent* ) nxEvent 

OntoAbstractEvent: (AbstractEvent **) returnEvent; 

//... 
#endif 
//... 
@end 

©implementation SystemEventDispatcher 
{ 

// ... 

HashTable* button PressEventObservers; // contains all 
Controls 

// interested in 
button 

// press events 
hashed by 

// window id. 

//... 

} 

+ (SystemEventDispatcher) eventDispatcher 

{ 
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// create a new instance of a system event dispatcher 
static SystemEventDispatcher* event Dispatcher - nil; 
if (eventDispatcher - - nil) { 

eventDispatcher - [[SystennEventDispatcher 

alloc] inil]; 

} 

return eventDispatcher; 

} 

- run 

{ 

// run the event dispatcher, fetching events from the 
system, 

// mapping them from the platform specific form into 
the 

// abstract mapping and subsequently dispatching them 
to all 

// eligble observers ... 
for {;;) { 

AbstractEvent* absev; 

#ifdef XWindows 

[self _mapXEvent: [self _nextXEvent] 
OntoAbstractEvent: &absev 

]; 

#endif 

#ifdef NeXTSTEP 

[self _mapNXEvent: [self _nextNXEvent] 
OntoAbstractEvent: &absev 

]; 

#endif 
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[self dispatch AbstractEvent: absev]; 

} 

} 

- (void) dispatch AbstractEvent: (AbstractEvent*) absev 
{ 

// dispatch abstract events to eligible observers 
switch {[absev eventType] { 

//... 

case AEButtonPress: 

// Find the COntrol associated with the 
window id 

// of the abstract event and dispatch the 

event 

// to it ... 

Control* c - [buttonPressEventObservers 
valueForKey: [absev 
eventWindow] 

]; 

(c gotButtonPressEvent: absev 
FromSource: self 

1; 

break; 
//... 

} 

} 

- (Bool) addObserver: Objea* observer 

forProtocol: Protocol* interestProtoco! 

{ 
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// register observer (if eligble) for particular observer 

protocol 

// ... 

if (interestProtoco! - - 
©protocoKAbstractButtonPressEventObserverProtocol) && 

[observer conformsTo: interestProtocol]) { 

// if the observer conforms to the protocol 

save it in a 

// hash table indexed by its window 
identifier. 

(buttonPressEventObservers 

insertKey: (const void [observer 
window]; 

value: (void *) observer 

1; 

} 

// ... 

return (BooI)True; 

} 

II ... 

@end 

©implementation 

SystemEventDispatcher(PlatformDependentStufO 
#ifdef XWindows 
II ... 

- (void) _mapXEvent: (XEvent* ) xEvent 

OntoAbstractEvenf. (AbstractEvent **) returnEvent 

{ 
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// platform dependent code to map system events onto 
event abstractions 
switch (xEvent->type) { 
//.,. 

case Button Press: { 

XButtonPressedEvent* xPress - 

(XButtonPres5edEvent*)xEvent; 
// create a new Abstracts uttonPressE vent 
*returnEvent - [AbstractButtonPressEvent 
new]; 

// here we initialize the member vars of 
the 

// AbstractButtonPressEvent based upon 
the 

// platform dependent information found 
in the 

// XButtonPressedEvent 
// ... 

} 

break; 
// ... 

} 

} 

II... 
#endif 

#ifdef NeXTSTEP 

//... 

#endif 

@end 

A simple exemplary "main" program demonstrates a ButtonControl that will receive abstract notifications of button 
presses from the SystemEventDispatcher: 
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int main(const int argc, const char **const argv) 
{ 

[ButtonControl newBunonControl]; // create a 
ButtonControl 

[(SystemEventDispatcher eventDispatcher] run]; // run 
the dispatcher 

} 



In accordance with the present irwenlion. the abstract notification of behavioral specifications, in conjunction with 
the went dispatch object, provides an ability to runtime negotiate whether a particular object in the graphical user irter- 
face tool!* confomis to the notification, as described with respect to step 208 of Rgure 2. The ability to provide runtime 
conformance testing, referred to herein as runtime negotiation, allows relationships between objects in a view field ver- 
sus objects in a control or model field to change dynamically during the execution lifetime of the system. In ttie mem- 
plary Figure 3 system, runtime negotiation allows relationships to be dynamically altered (i.e.. established and de- 
established) via a remapping within the event dispatch object 

To better illustrate the foregoing features, and in particular the mntime negotiation feature, consider two anony- 
mous objects: one in a window-based platform and the other in the graphical user interface. The two objects know only 
of each other's exislenoe and nothing else. The two objects will be referenced herein as a "vendor" and as a customer . 
A vendor 402 and a customer 404 are graphically illustrated in Rgure 4. , »u 

Assuming that the behavioral specification of the vender includes a protocoiwWch the customer (e.g.. the customer 
of a client-side application) wants to use. such as a keypress event, the vender must be able to export some notificabon 
of keypress events to the customer The customer knows of the vender's existence, and is interested m entering a rurrt- 
ime negotiation to verify its ability to pass information {e.g.. notifications) to the vender The customer therefore needs 
to know if the vender confonns with the customer's behavioral specifications. 

Given this starting position, the runtime negotiation is initiated by the customer querying the vender as to whether 
it vends the behavioral specification "A" (I.e.. the protocol which the customer wants to use). If the vender does not vend 
the behavioral specification "A", the customer discontinues its attempt to establish an information transfer with the 
vender However. If the vender indicates that it does vend the behavioral specification "A", the customer registers an 
"interesT with the vender for the behavioral specification corresponding to "A". Because the vender supports this behav- 
ioral specification, the customer infomis the vender that it wants to participate in this behavioral specification with the 
vender so that the vender can transfer infomiation to a view of the customer, whenever state changes associated with 
this behavioral specification occur. -^.^.^..^h-. 

Once the customer confirms that it wants to participate in the behavioral specif icaton and negotiate with the vender 
to receive notifications regarding state changes, the vender queries the customer as to whether it conforms (i.e.. 
adheres) to the behavioral specification "A". Assuming that the customer does confomi with the behavioral specification 
"A", a relationship (i.e.. runtime contract) is established, such thai abstract notifications can flow between these two 

"'''^raccordance vinth exemplary embodiments, at any time during the execution life of the system, the vender and/or 
customer can withdraw from the relationship. That is, either object can remove itself from the relatonship. Such a 
removal may be desirable H. for example, the customer completes its job and resigns from the relationship. \i either 
object resigns from the relationship, then new relationships can be established in the manner already described. 

Having described an exemplary runtime negotiation, attention is now directed to an exemplary mapping of objects 
to one another in accordance with the present invention. In this regard, reference is made to Rgure 5. wherein an event 
correspondingto the activation of apush button on adisplay of awindow-based system isto be used to trigger an event, 
m accordance with exemplary embodiments, concrete information corresponding to this event is mapped from the win- 
dow-based platform into abstract information by the graphical user interface in the manner described previously Here, 
a push button 502 is represented in a client-side object oriented graphical user interface, as an object with corresponds 
to both a view and to a controller of the model-view-controBer paradigm. As a view, it is responsible for drawing the push 
button on a display. As a controller, it describes state changes which occur to indicate that the push button is depressed 
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or released. 

Assume that the behavioral specrfication for the push button includes a protocol "Button Clid«", that produces two 
messages: (1) push button depressed; and (2) push button released. In the case of a push button, the abstracted noti- 
fication can further include information which identifies the time at which it was depressed (i.e., a time stamp), keyboard 

5 modifiers which were activated with the push button (e.g,. activation of the shift key with a letter key), or the position of 
a mouse at the time of push button activation (ag., where the button on the mouse was activated). Assume further that j 
the event dispatch object vends the "Button Clicks" protocol. During a runtime negotiation, the push button queries the 
event dispatch object as to whether it vends the "Button Clicks" protocol. If the event dispatch object 504 does vend this 
protocol, the push button responds by indicating that it wants to participate in the "Button Clicks" protocol with the event 

10 dispatch object The push button therefore registers an "interest" in the "Button Clicks" protocol. 

The event dispatch object next queries the push button as to whether it conforms to the "Button Clicks" protocol. If 
the push button answers affirmatively, a relationship is established. As such, when the event dispatch object receives a 
button press e/ent from the window-based platform 506, It then notifies the push button of a "push button depress" 
event. 

IB Because exemplary embodiments of the present invention abstract events, certain information which is implemen- 
tation specific may, of course, be lost. However, in return for any lost information enhanced portability of the system is 
achieved. Further, as those skilled in the art will appreciate, any implementation specific information can be retained by 
specifically encoding this in the client-side object oriented graphical user interface for the platform specific implementa- 
tion. 

20 Referring again to Figure 5, those skilled in the art will appreciate that when notifications are abstracted as 
described above, a 1 :1 relationship between objects need not be maintained. Rather, all of the objects having an "inter- 
est" in the abstract notification can be mapped to receive the notification. For example, where the abstract notification 
corre^onds to the output of a timer 508, an associated protocol "tick" can be established to inform the event dispatch 
object every time one second passes. A separate "Timeflow" protocol can then be established between the event dis- 
ss patch object and all objects (e.g.. objects 51 0 and 512) having an "interest" in tracking time. Such objects may include, 
for example, a clock on the display, a stock market ticker feed, a timer and so forth. The views of all objects having an 
interest in tracking time are thus notified of changes in time via the "Tlmeflow" protocol. Accordingly, even though the 
"tick" protocol has a 1 :1 relationship with the event dispatch object, the "Timeflow" protocol represents a relationship of 
the event dispatch object with all objects having an interest in tracking time. 
30 Those skilled in the art will appreciate that exemplary embodiments of tine present invention can be implemented 
in many different ways. For example, exemplary embodiments can be used to port features of a graphical user interface 
to a window-based system implemented in eitiier software or hardware. Further, afthough exemplary embodiments 
have been described in the context of a client server system, those skilled in the art will appreciate tiiat features of tiie 
invention can be used to port a toolkit of a graphical user interface to any window-based system(s) regardless of where 
35 the window-based system(s) resides. 

It will be appreciated by tinose skilled in tiie art tiiat the present invention can be embodied in other specific forms 
without departing from the spirit or essential characteristics thereof. The presentiy disclosed embodiments are therefore 
considered in all respects to be illustrative and not restricted. The scope of the invention Is indicated by the appended 
claims rather ttian tiie foregoing description and all changes tiiat come within tiie meaning and range and equivalence 
40 thereof are Intended to be embraced theran. 

Claims 

1 . A method for porting a toolkit of a graphical user interface to a window-based platform comprising tiie steps of: 

45 

receiving a native notification of a state change from a vinndow-based platform; and 

representing said native notification as an abstracted notification during execution of ttie graphical user inter- 
face, said abstracted notification constituting a behavioral specification of the native notification which is inde- 
pendent of implementations specific to said window-based platform. 

so 

2. A metiiod according to claim 1 , further comprising a step of: 

configuring said graphical user interface to, during execution of said graphical user interface, verify conform- 
ance of at least one object in tiie graphical user interface toolkit with said behavioral specification. 
55 ~- ~~ ^ ^ " ^ "~ ^ ^ ^ ^ • 

3. A method according to claim 1, wherein said step of representing a native notification furtiier includes a step of: 

defining said behavioral specificatipn as a functional signature of a window-based platform event. 
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4. A method according to daim 2. further comprising the step of: 

registering at least one abstracted notification with at ieast one object o1 said toolldt dynamically during runtime 
execution of said graphical user interface. 

5. A method according to daim 4, wherein said step of registering further indudes a step of: 

registering said abstracted notification with multiple objects of said toolkit dynamically during mntime execution 
of said graphical user interface toolkit 

6. A graphical user interface toolkit for use with a window-based platform, said graphical user interlace toolkit com- 
prising: 

an input for receiving native notifications of state changes from a window-based platform; and 
a hierarchical coliectbn of objects which establish relationsNps with abstractions of said native notifications 
that are represented as abstracted notifications, said abstracted notifications constituting behavioral specifica- 
tions of the native notifications which are independent of implementations specific to said window-based plat- 
form. 

7. A graphical user interface toolkit according to claim 6, further comprising: 

an output for sending said abstracted notif icatons to the window-tased platform. 

8. A graphical user Interface toolkit according to daim 6, wherein said hierarchical collection is configured to register 
at least one abstracted notification wrth at least one object of said hierarchical collection dynamically during runtime 
execution of said graphical user interface. 

9. A graphical user interface toolkit according to claim 6. wherein at least' one of said abstracted notifications is regis- 
tered with multiple objects of said hierarchical collection of objects. 

10. A graphical user interface according to claim 8, wherein said Werarchial collection is configured to verify conform- 
ance of said at least one object to said at ieast one abstracted notification during runtime execution of said graph- 
ical user interface toolkit 

11. A graphical user interface toolkit according to daim 6. wherein said toolkit is implemented in a client side of di- 
ent/server network. 

1 2. A graphical user interface toolkit according to claim 6, wherein said native notifications of state changes in said win- 
dow-based platform are provided to models, views and controllers used to define interactions between said objects 
of said hierarchical collection. 

13. A computer readable medium encoding a program of instructions used to execute a method for porting a toolkit of 
a graphical user interface to a window-based platform comprising the steps of: 

receiving a native notification of a state change from a window-based platform; and 

representing said native notification as an abstracted notification during execution of the graphical user inter- 
face, said abstracted notification constituting a behavioral specification of the native notification which is inde- 
pendent of implementations specific to said window-based platfonn. 

14. A computer readable medium according to claim 13. further programmed to implement a step of: 

including the abstracted notification in at least one object dass of tiie graphical user interface. 

1 5. A computer readable medium according to daim 13. furtiier programmed to implemerit a step of: 

verifying conformance of at least one object in tiie graphical user interface toolkit with said behavioral specHi- 
cation during execution of said graphical user interface. 
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1 6. A computer programmed product encoded with a computer program for porting a toolkit of a graphical user inter- 
face to a window-based platform, comprising: 

a computer readable storage medium for storing data; and 

a computer code mechanism embedded in the computer readable storage medium for causing the computer 
readable storage medium to execute said computer code, said computer code mechanism further including: 

a first computer code device for receiving a native notification of a state change from a window-based plat- 
form; and 

a second computer code device, coupled to the first computer code device, for representing said native 
notification as an abstracted notification during execution of the graphical user interface, said abstracted 
notification constituting a behavioral specification of the native nottfication which is independent of imple- 
mentations specific to said window-based platform. 

1 7. A computer programmed product according to daim 1 6, wherein said computer code medianism further includes: 

a third computer code device for verifying conformance of at least one object In the graphical user interface 
toolkit with said behavioral specification. 
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(57) The present Invention is directed to providing • 
an ability to re-host, or port an object oriented graphical 
user interface implementation from a native window- 
based platform, or environment, to another window- 
based platform, or environment Exemplary embodi- 
ments abstract any notifications (e.g., events, state 
changes or "interests") which occur in the native envi- 
ronment as behavioral specifications. These behavioral 
specifications, (i.e.. traits or protocols) can be used as 
part of a conformance negotiation to determine, during 
the execution lifetime of the graphical user interface, 
whether a particular client side object will conform with 
the behavioral specifications which have been 
abstracted from server side events assodated with a 
different object Where the conformance negotiation 
proves successful, abstract notifications can flow 
between particular instances of objects to mode! the 
state of the system, rather than using native implemen- 
tations of events. During the execution lifetime, other 
objects can dynanilcally establish relationships with 
object classes containing abstracted notifications for the 
purpose of receiving the abstracted notifications. 
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